1. The Field of the Invention
The present invention is generally related to Reliable Messaging protocols for distributed systems, e.g., Web Services. More specifically, the present invention provides for a binding of Reliable Messing protocols for distributed systems to request-response transport protocols (e.g., HTTP) in a one-way message exchange pattern environment.
2. Background and Related Art
Computer networks have enhanced our ability to communicate and access information by allowing one computer or device to communicate over a network with another computing system using electronic messages. When transferring an electronic message between computing systems, the electronic message will often pass through a protocol stack that performs operations on the data within the electronic message (e.g., parsing, routing, flow control, etc.). The Open System Interconnect (OSI) model is an example of a network framework for implementing a protocol stack.
The OSI model breaks down the operations for transferring an electronic message into seven distinct layers, each designated to perform certain operations in the data transfer process. While protocol stacks can potentially implement each of the layers, many protocol stacks implement only selective layers for use in transferring data across a network. When data is transmitted from a computing system, it originates at the application layer and is passed down to intermediate lower layers and then onto a network. When data is received from a network it enters the physical layer and is passed up to the higher intermediate layers and then is eventually received at that application layer. The application layer—the upper most layer—is responsible for supporting application and end-user processing. Further, within the application layer there may reside several other layers (e.g., the Simple Open Access Protocol (SOAP) layer). Another layer incorporated by most protocol stacks is the transport layer. An example of a transport layer is the Transmission Control Protocol (TCP).
Web Services (WS) have been a driving force in advancing communications between computing systems and are turning the way we build and use software inside-out. Web Services let applications share data and—more powerfully—invoke capabilities from other applications without regard to how these applications where built; what operating systems or platform they run on; and what devices are used to access them. Web Services are invoked over the Internet by means of industry-standard protocols including SOAP, XML (eXtensible Markup Language), UDDI (Universal, Description, Discovery and Integration), WSDL (Web Service Description Language), etc. Although Web Services remain independent of each other, they can loosely link themselves into a collaborating group that performs a particular task.
Current WS technologies offer direct SOAP-message communication between an initiator (e.g., a client) and an acceptor (e.g., a service). In the common bi-directional messaging case, a SOAP request message is sent from the initiator to the acceptor and a SOAP reply message is sent in response thereto. Another communication variant between endpoints is unidirectional message, where the initiator sends a message to the acceptor with no response.
A key benefit of the emerging WS architecture is the ability to deliver integrated, interoperable solutions. Because, however, Web Services provide various services from different business, originations, and other service providers via unreliable communication channels such as the Internet, reliability of WS becomes an increasing important factor. Reliability of WS is impacted by several factors including but not limited to, the reliability of the Web Service endpoints; reliability characteristics of the communication channel over which the Web Services are accessed; performance and fault-tolerance characteristics; and the extent to which Web Services can handle concurrent client access.
There have been attempts at accomplishing reliable messaging of Web Services by choosing a reliable transport protocol over which the messages (e.g., SOAP messages) are exchanged between endpoints. For example, a reliable messaging transport such as message-queues can be used to deliver messages reliably between initiators and acceptors. Message-queuing communication technologies enable applications on different systems to communicate with each other by sending messages to queues and reading messages from queues that are persisted across failures for reliability.
Although queuing systems offer a transport that can be used to carry SOAP messages reliably, there are several drawbacks to such systems. For instance, these systems offer solutions for an asynchronous operation where the requests (and possibly their responses) are transferred and processed with isolation. Accordingly, these systems are typically heavyweight in terms of resources; involving multiple intermediaries with durable transacted message stores and with considerably more complexity in deployment, programming model and management. All of this is unnecessary for reliable direct communication, and detracts from the goal of minimizing latency. Further, the program model does not directly support request-response style programming or sessions. Accordingly, the queued communication model is different from the current “interactive” Web Services model, and does not address critical “connected” scenarios and “interactive” applications. For example, it is not well suited for cases where a response is expected in a timely manner, or for cases where distributed-transaction-context need to be shared between initiator and acceptor.
There have also been attempts at defining reliable transfer layers over fundamentally unreliable transport protocols, e.g., reliable HTTP or HTTPR. A common problem, however, that plagues this solution—as well as the queuing solution—is that reliable messaging can be achieved only if the specific reliable transport protocol is used for communication between the initiator and the acceptor. The fundamental nature of Web Services calls for independence from specific vender platform, implementation languages and specific transport protocols. In a generic case, an initiator may not be able to transmit a message directly to an acceptor using a particular protocol (e.g., acceptor does not support the protocol) or the message may need to pass through multiple hops after leaving the sending node prior to arriving at that destination node. Depending on the nature of the connectivity between the two nodes involved in a particular hop, a suitable transport protocol that does not offer reliable messaging characteristics may have to be chosen.
Intermediaries may also exist at different levels in the protocol stack; and therefore, not offer full end-to-end reliability. For example, transport protocols may offer reliability across lower level intermediaries (e.g., IP level intermediaries—e.g., IP routers). The transport protocol may end, however, at a SOAP intermediary or application layer (e.g. an HTTP Proxy). Accordingly, the transport protocol may not be able to offer reliability across that intermediary, i.e., no end-to-end reliability across the application layer.
More recently, various Reliable Messaging protocols for distributed systems (hereinafter referred to as “RM protocols”), offer solutions to the above identified-deficiencies of current reliable messaging systems. These protocols (e.g., RM protocols for Web Services (WS), which include WS-ReliableMessaging, WS-Reliability, etc.) are transport agnostic connected protocols that allow messages to be delivered reliably between endpoint applications in presences of software component, system or network failures. Accordingly, RM protocols offer solutions for reliable, end-to-end, and potentially session-oriented communication between an initiator and an acceptor.
These RM protocols are akin to TCP in that TCP offers reliable, exactly-once, in-order delivery of a stream of bytes from a TCP sender to TCP receiver across Internet Protocol (IP) routers and multiple networks. Reliable Messaging protocols for distributed systems offer the same and more for messages (note: the unit of transfer is a message, not a byte) across multiple intermediaries (including transport and SOAP level intermediaries), transports and connections. Although TCP and RM protocols are both “reliable” protocols, because RM protocols (and, more generally, the SOAP layer) reside at the application in the OSI model, RM protocols provide for reliable messaging regardless of the transport protocol used to transfer the data. Accordingly, RM protocols are not tied to a particular transport or other protocol used to transfer message between endpoints.
Although a few RM protocols have been around for some time there are still several drawbacks and deficiencies of these protocol specs. For example, Reliable Messaging protocols for distributed systems typically require bi-directional message exchange; i.e., application messages go in one direction and infrastructure acknowledgments go in the other direction. Further, there are cases where unsolicited acceptor-to-initiator communication is not possible; for instance, when the initiator is behind a firewall and uses a request-response transport protocol (e.g., HTTP) connection (by, e.g., tunneling through a HTTP proxy) to communicate with the acceptor. A problem arises, however, in being able to send acknowledgments and other infrastructure messages to the initiator since the initiator is typically not addressable and/or communication is restricted to a request-response transport protocol. Accordingly, a need arises for orchestrating the reliable sending of application-level messages in a one-way message exchange pattern from an initiator to the acceptor—and RM infrastructure messages in both directions—over a transport that offers a request-response messaging pattern.